1. Field of the Invention
The present invention relates to a method for Ternary Contents Address Memory (TCAM) table management and a computer-readable recording medium for recording a program that implements the method; and, more particularly, to a method for TCAM table management, which is capable of maximizing memory utility of TCAM by effectively classifying and storing routing entries in the TCAM lookup table and also updating the lookup table for newly inputted routing entries more quickly and effectively, and a computer-readable recording medium for recording a program that implements the method.
This work was supported by the Information Technology (IT) research and development program of the Korean Ministry of Information and Communication (MIC) and/or the Korean Institute for Information Technology Advancement (IITA) [2005-S-101-02, “Multimedia QoS Routing Technology Development”]
2. Description of Related Art
In general, a router extracts a destination address of packet inputted for forwarding an Internet Protocol (IP) packet and looks up a forwarding table by using the extracted destination address as a key, to determine a next hop where the packet is to be forwarded. Such a routing lookup is performed in every router hop through which the packet passes, so that the packet eventually reaches from its originating node to the destination node.
A destination address of IP packet consists of a network address and a host address. Meanwhile, with the exponential growth of the Internet, a Classless Inter-Domain Routing (CIDR) scheme was adopted for more efficient and flexible use of IP address space in 1993. In the CIDR scheme, IP packet address is expressed simply in prefix/mask, not in IP network and host addresses. For example, in case of IPv4 using 32 bits, 129.254.191.xxx corresponding to the upper 24 bits of the mask in 129.254.191.0/24 is used as a network prefix address, and the remaining lower 8 bits are not used. Due to the address system of the CIDR scheme, it is required that a router stores numerous routing prefix addresses in a routing table, and a prefix address matching a destination address the longest (longest prefix match) in the IP lookup is determined as a resulting value. To help understand the foregoing, the longest prefix match will be described below with reference to FIG. 1.
FIG. 1 is an exemplary view for explaining a longest prefix match.
Referring to FIG. 1, three routing prefix addresses 11.1.2.0/24 (110), 11.1.0.0/16 (115), and 11.1.0.0/8 (120) are stored in a routing table, and a destination address 11.1.2.5 (105), which is the key value for IP lookup, is also stored therein. Further, there are binary expressions for the destination address 105 and each of the routing prefix addresses 110, 115, and 120 in FIG. 1 (the right side). The routing prefix address “110” has a 24-bit prefix length, the routing prefix address “115” has a 16-bit prefix length, and the routing prefix address “120” has an 8-bit prefix length. Therefore, the routing prefix address “110” matches with the destination address 11.1.2.5 (105) because only the upper 24 bits thereof are compared with each other. Similarly, the routing prefix address “115” matches with the destination address 105 because only the upper 16 bits thereof are compared with each other, and the routing prefix address “120” matches with the destination address 105 because only the upper 8 bits are compared with each other. Although these three routing prefix addresses 110, 115, and 120 all can be a resulting value for the destination address 105, the routing prefix address “110” with the longest prefix match, i.e., 24 bits, should be determined as a final resulting value.
As the scale of the Internet increased, the size of a lookup table to be stored in a router has increased. To cope with this and for longest prefix match in an enormous lookup table, a method for high-speed operation and efficient routing table management has been required. Traditionally, a software based method using hashing or trees have been frequently used as IP lookup technology used for development of a router. The software based IP lookup technology is advantageous in that it is easy to implement and is flexible for correction. However, as a memory has to be looked up several times for looking up for one destination packet, the above technology cannot meet the high-speed packet processing due to its slow speed.
Therefore, in recent years, a hardware based IP lookup technology using Content Addressable Memory (CAM) is often used for high-speed IP lookup, instead of the software based IP lookup technology. The CAM is a memory device that executes a search operation such as looking up for a corresponding match entry in a routing table in one clock cycle. That is, an input search key to the CAM is parallely compared with every entry in the CAM, to output a location where a corresponding entry is stored or its data.
Meanwhile, a Ternary CAM (TCAM) provides the function of expressing a mask of a routing prefix address stored in the routing table. The “ternary” used herein means that a value of information inputted to the TCAM can indicate the state of “don't care”, in addition to “0” and “1” of binary values. For example, in case of the IPv4 routing prefix 129.254.191.0/24 in TCAM, the upper 24 bits are expressed in “1 or “0”, while the remaining 8 bits can be expressed in “don't care” since they are not used.
Such a TCAM enables high-speed IP lookup processes, but by nature of the TCAM, a result stored in the highest address becomes always a final result when there are a number of match results. Therefore, for a longest prefix match, an arranged state should be maintained in a manner that a routing entry with a long prefix length can be always stored in a higher address than routing entries with relatively shorter prefix lengths. For a better understanding about this, how the results change depending on TCAM table arrangement states for a longest prefix match will now be described with reference to FIG. 2.
FIG. 2 is an exemplary view for explaining a longest prefix match process in TCAM.
Referring to FIG. 2, in a TCAM table 230 that is not arranged, a routing entry 129.254.xxx.xxx/16 (205) having a 16-bit prefix length is located in a virtual highest address 0 of the TCAM, and routing entries 129.254.12.xxx/24 (210), 129.254.14.1xx/30 (215) and 129.254.11.xxx/24 (220) are stored in memory addresses 1, 2, and 3 of the TCAM, regardless of the order of prefix lengths. In this case, when a TCAM lookup is performed with respect to the destination address 129.254.11.123 (200) inputted, routing entries “205” and “220” with TCAM addresses 0 and 3 match with the destination address, respectively. Thus, by the nature of the TCAM, a result value existing in the highest address in the TCAM table is selected, so the final lookup result will be “205” located in the address 0. However, this result does not meet the longest prefix match because the final result should have been “220” having a 24-bit prefix length, which is actually longer than “205” having a 16-bit prefix length.
On the other hand, in case of a table 235 that is arranged in the order of longer prefix, no matter how many lookup results may exist, a routing entry having the longest prefix length is always stored at the top location of the TCAM, so the longest prefix match is satisfied all the time. Therefore, the method for a TCAM lookup table management that maintains a state where routing entries stored in the TCAM are always arranged in the order of longer prefix is very essential to implement the high-speed lookup technology using the TCAM.
The following is a description for a conventional method for a TCAM table management for maintaining an arranged state of a lookup table with reference to FIG. 3.
FIG. 3 illustrates a conventional TCAM table structure for a longest prefix match, in which a 32-bit IPv4 is provided as an example.
Referring to FIG. 3, the conventional method for the longest prefix match was done simply by locating a routing entry having the longest prefix length at the top, routing entries having relatively shorter lengths at lower locations, and an empty memory space of the TCAM that is not yet allocated is located at the lowest location.
In this case, when a new routing entry is added, the TCAM table changes according to the following scenario. In case the newly added routing entry has a 30-bit prefix length, a memory location of the TCAM must be at a lower memory position than routing entries having a 31-bit prefix length and at a higher memory position than routing entries having a 29-bit prefix length so as to meet the longest prefix match. Therefore, a location for the memory address 3 (315) which is lower than “300”, “305”, and “310” in FIG. 3 will be appropriate. But, since a routing entry “315” having a 29-bit prefix length is currently stored in the memory address 3, it is necessary to move “315” first. “315” having a 29-bit prefix length may be moved to the memory address 4, but the memory address 4 has also been allocated to the routing entry “320”, which means that the “320” routing entry has to be moved as well. After moving all the routing entries of memory addresses 4 to N−1 one by one to lower positions in this way, the new routing entry can be stored in the empty memory address 3. In other words, when the number of routing entries currently being stored in TCAM is 1 million, the worst scenario would be moving all of the 1 million routing entries one by one to lower positions in worst cases, and then inputting a new entry.
As described above, the conventional TCAM routing table arrangement method for the longest prefix match may not be efficient because many existing routing entries have to be moved. Moreover, in case of a high-speed router, the lookup process required for actual packet forwarding itself is heavily affected when TCAM table update takes too long. Therefore, a new method for resolving these is necessary. Even though several schemes for complementing the routing table management performance have been suggested, most of them have unsatisfactory efficiency and wasted a large amount of memory space of TCAM.